The  Pennsylvania  State  University 

APPLIED  RESEARCH  LABORATORY 

P.O.  Box  30 

State  College,  PA  16804 


AN  ELECTRONIC  INTERFACE  FOR  A  FIBER  OPTIC 
TETHERED  UNMANNED  UNDERWATER  VEHICLE 


by 


J.  R.  Sheakoski 


Technical  Report  No.  TR  94-08 
April  1994 


dtic_ 

elect E  ^ 

W«101994|| 

G  ^ 


Accesion  For 


NTIS  CRA&I 
DTIC  TAB 
U  a  ’.rou:xed 
J  istification 


I 

□ 


By . 

Di-t  ibatioii/ 


Availability  Codes 

Dist 

Avail  c 
Spe 

ind/or 

cial 

Supported  by: 

Naval  Sea  Systems  Command 


L.R.  Hettche,  Director 
Applied  Research  Laboratory 


Approved  for  public  release;  distribution  unlimited 


REPORT  DOCUMENTATION  PAGE 


OM§  MOl  OTM-OfW 


ANO  SUtrtTU 


An  Electronic  Interface  for  a  Fiber  Optic  Tethered 
Unmanned  Underwater  Vehicle 


AU 

J.  R.  Sheakoski 


7.  MWORMNM  ORCANUATtOM  NAMi($)  ANO  AOO«f$S(fS) 

Applied  Research  Laboratory 
The  Pennsylvania  State  University 
P.O.  Box  30 

State  College,  PA  16804 


9,  SfONSOlUNC/MONrrOlUNG  AGCNOr  NAMflSTANO  AOOA(SS<ISl 

Naval  Sea  Systems  Command 
2531  National  Center,  Building  3 
Washington,  DC  20362-5160 


S.  njNOWC  NUMMRS 

N00039-88-C-0051 


I.  nitFORMMG  ORCANUATION 

RirORT  NUMMR 


TR-94-08 


10.  SPONSORING  /  MONITORING 
AGINCV  RIPORT  NUMMR 


lia.  mtrirution/avanlaiiuty  statimint 

12b.  0«$TRI9UTK>N  COOf 

Unlimited 

13.  ARSTlua  (M««Mn««m^00iro««W 

As  the  sophistication  of  acoustic  sensor  and  communication  systems  related  to 
unmanned  underwater  vehicles  (UUV)  has  Increased,  the  requirement  for  greater 
volume  and  higher  speed  data  transfers  has  emerged.  Fiber  optic  technology 
provides  an  effective  means  for  high  bandwidth  communications  with  a  UUV  while 
minimizing  weight  and  space  criteria  aboard  the  UUV.  Increase  in  data  transmission 
speed  has  permitted  real  time  processing  of  data  on  the  launch  platform  when 
using  large  high  powered  computing  systems.  Maximum  system  reliability  at  advanced 
performance  levels  can  also  be  realized.  By  designing  and  developing  a  full 
scale  system  comprised  of  the  UUV,  remote  control  and  command  platform,  and  data 
handling  and  routing  electronics,  fiber  optic  tethered  UUV  technology  was 
demonstrated  in  lab  field  tests.  This  three  year  venture  culminated  in  a  series 
of  successful  In-water  tests  that  proved  the  feasibility  of  fiber  optic  tethered 
UUV's  and  warranted  the  continuation  of  research  on  remotely  operated  UUVs. 


14.  SUtlta  TIRMS 

fiber  optic,  tether, 
high  bandwidth,  real 

UUV.  acoustics,  communication,  data  transfer. 

19.  NUMMR  OP  PAMS 

84 

time,  remote  control. 

command 

19.  PRia  COOf 

17.  sicuRrrr  oassipication 

OP  RIPORT 

18.  SICURmr  OASSNICATlbN 

OP  TMI9  PAGI 

19.  SiCURri>  OASSNOTION 
OP  ARsnua 

20.  UMITATION  OP  A8STRACT 

UNCLASSIFIED 

UNCLASSIFIED 

UNCLASSIFIED 

UNLIMITED 

NSN  ;S40-01-2IO-S500 


Standard  form  299  (R#v  2-89) 
e*  •*!»<  'I 


ABSTRACT 


As  the  sophistication  of  acoustic  sensor  and  communication  systems  related  to 
unmanned  underwater  vehicles  (UUV)  has  increased,  the  requirement  for  greater  volume 
and  higher  speed  data  transfers  has  emerged.  Fiber  optic  technology  provides  an 
effective  means  for  high  bandwidth  communications  with  a  UUV  while  minimizing 
weight  and  space  criteria  aboard  the  UUV.  Increase  in  data  transmission  speed  has 
permitted  real  time  processing  of  data  on  the  launch  platform  when  using  large  high 
powered  computing  systems.  Maximum  system  reliability  at  advanced  performance 
levels  can  also  be  realized.  By  designing  and  developing  a  full  scale  system  comprised 
of  the  UUV,  remote  control  and  command  platform,  and  data  handling  and  routing 
electronics,  fiber  optic  tethered  UUV  technology  was  demonstrated  in  lab  and  field  tests. 
This  three  year  venture  culminated  in  a  series  of  successful  in-water  tests  that  proved  the 
feasibility  of  fiber  optic  tethered  UUVs  and  warranted  the  continuation  of  research  on 
remotely  operated  UUVs. 
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CHAPTER  1 
INTRODUCTION 


With  the  use  of  a  single  fiber  as  the  communication  link  between  the  UUV  and 
launch  platform,  the  success  of  the  overall  system  relies  partially  on  accurately 
converting  all  communicated  information  into  a  serial  data  stream.  The  data  stream 
will  then  be  transmitted  optically  over  the  fiber.  The  task  of  converting  the  serial 
data  stream  into  data  that  is  useable  by  the  subsystem  electronics  is  accomplished  by 
additional  custom  electronics  that  can  multiplex/demultiplex  and  interface  effectively 
to  the  processing  and  control  equipment. 

This  thesis  will  discuss  the  development  of  a  system  that  utilizes  an  optical 
medium  for  data  communications,  and  more  specifically  the  design  development  and 
integration  of  the  data  handling  electronics  on  either  side  of  the  optical  subsystem. 

1.1  Fiber  Optic  Tethered  Vehicles 

A  tethered  UUV  is  an  underwater  vehicle  capable  of  performing  various 
missions  without  having  in-water  personnel  [1].  Tethered  UUVs  can  operate  in 
hazardous  conditions  or  in  bad  weather.  They  can  operate  in  areas  that  are 
dangerous,  confined,  or  otherwise  not  suited  for  manned  vehicles.  Because  it  is 
unmanned,  the  UUV  is  fearless  and  does  not  have  to  provide  support  for  man  or 
extensive  equipment  [2]. 


Tethered  UUVs  are  used  for  operations  as  search  and  recovery,  underwater 
construction,  assembly,  and  inspection.  They  are  best  suited  for  large  seafloor  area 
coverage,  single  task  missions,  and  are  clearly  superior  for  hazardous  circumstances. 

1.2  Fiber  as  a  Data  Transmission  Medium 

The  goal  of  the  fiber  optic  tether  is  to  provide  a  simple  error  free  link  that  w  ill 
interface  different  equipment  and  tolerate  the  varying  communication  losses  in  the 
system  [3].  The  link  is  the  lifeline,  communicating  real  time  data  and  control  to  and 
from  the  UUV.  The  communication  link  must  be  able  to  handle  high  speed  data  and 
large  volumes  of  data  [4].  Additionally,  its  supporting  electronic  interfaces  must  be 
able  to  maintain  the  link  through  proper  use  and  respect  for  the  maximum  link 
bandwidth. 

Fiber  is  an  unequaled  communication  link.  For  an  individual  single  mode 
fiber,  an  unlimited  bandwidth-length  product  is  theoretically  possible,  but  not 
practical.  Viable  transmission  distance  is  affected  by  two  parameters,  dispersion  and 
attenuation  [5].  Current  links  operate  at  less  than  5  GHz.  As  a  transmission  media, 
links  can  be  realized  that  communicate  greater  than  250  km  without  repeaters  [6]. 
Additionally,  optical  transmitters  of  different  wavelengths  can  use  the  same  fiber 
simultaneously  without  interference.  Being  able  to  use  the  same  fiber  simultaneously 
multiplies  the  carrying  capacity  by  the  number  of  wavelengths  used. 

The  optical  link  offers  the  great  advantage  of  very  high  speed  and 
simultaneous  bidirectional  data  communications.  Fiber  has  the  additional  advantages 
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of  a)  electrical  isolation,  b)  no  short  circuits,  c)  wide  bandwidth  with  low  attenuation, 
d)  transmission  security,  e)  no  crosstalk,  and  0  no  fire  hazards  [5],  Fiber  is  also 
small  in  size  and  light  weight.  A  typical  fiber  for  deployment  could  be  less  than  1mm 
in  diameter  and  weigh  1  kg/km,  while  a  coaxial  cable  with  a  comparable  bandwidth 
could  be  30  mm  in  diameter  and  weigh  1110  kg/km  [6].  For  UUVs,  a  fiber  link's 
size  and  weight  translates  to  extended  mission  lifetime  and  enhanced  packing  density 
for  the  spooled  fiber. 

1.3  Data  Handling 

In  order  to  accommodate  the  data  flow  across  the  optical  link,  typically, 
custom  electronics  are  designed.  The  design  is  custom  because  the  type  and  quantity 
of  interfaces  can  vary  greatly  and  the  interface  to  the  optics  is  user  specified. 

Interfacing  systems  can  exist  in  different  forms;  two  common  structures  are 
the  pipeline  and  bus  structure.  In  a  pipeline  configuration,  data  will  pass  through 
each  function  (or  interface)  one  at  a  time  to  arrive  at  the  final  destination  (optical 
interface).  The  throughput  of  the  system  is  limited  by  the  slowest  interface.  In  a  bus 
configuration,  all  of  the  functions  are  tied  to  a  common  point,  a  bus  type  structure. 

A  bus  is  a  communications  backplane  that  is  shared  for  intercommunications  among 
bus  modules.  Limitations  on  the  configuration  are  dependent  on  the  bus  bandwidth 
and  availability,  since  all  data  transfers  to  an  alternate  interface  must  pass  through  the 
common  bus.  The  bus  can  only  support  one  data  transfer  path  at  any  given  instant. 
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The  choice  of  the  system  utilized  in  this  thesis  was  obviously  directed  at  a 
central  bus  configuration  because  of  the  non-pipelining  organization  of  the  system 
processing.  For  reasons  to  be  discussed  in  detail  later,  the  VME  (Versa  Module 
Eurocard)  bus  was  chosen.  All  interfacing  within  the  two  unique  subsystems  (UUV 
and  launch  platform)  is  accomplished  using  the  VME  bus  structure  complete  with 
commercial  and  custom  designed  circuit  cards. 

The  objective  of  the  data  handler  is  to  provide  a  transparent  interface  that  joins 
the  two  separate  subsystems.  If  it  was  possible  to  keep  all  of  necessary  electronics 
inside  of  the  UUV,  the  data  flow  for  the  system  would  be  very  different.  Recorded 
data  could  be  routed  to  the  recorders,  acoustic  data  could  be  channeled  directly 
through  the  array  processors,  and  command  and  control  information  would  be  local  to 
the  UUV  and  provide  immediate  decisions  on  processed  data.  This  was  not  the 
situation  developing  for  this  system;  data  would  not  only  exist  in  the  UUV  but  also  at 
a  remote  location  that  also  required  the  data.  The  design  of  this  system  was  not 
simply  a  demonstration  of  a  tethered  vehicle,  but  needed  to  provide  the  computational 
power  required  for  the  experiment. 

A  powerful  processing  system  had  to  be  transferred  to  the  launch  platform 
where  there  were  no  restrictions  on  space.  Effectively  this  required  the  splitting  of 
the  system  electronics  and  the  addition  of  a  communication  link  between  them  that 
would  not  effect  the  overall  system  characteristics  or  operation.  This  required 
additional  electronics  evolved  into  the  development  of  the  Fiber  Optic- VME  Interface 
board  (FO-VME  I/F)  and  the  associated  optics. 
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1.4  Thesis  Objectives 

The  research  presented  in  this  thesis  is  part  of  a  much  larger  system  that  was 
involved  with  the  complete  system  development  of  a  fiber  optic  tethered  UUV.  This 
system’s  successful  completion  took  several  years  and  involved  the  hard  work  of 
many  engineering  disciplines.  This  thesis  will  discuss  one  specific  development 
within  the  system,  the  engineering  of  the  electronic  data  handler  (FO-VME  I/F)  on 
either  side  of  the  optics. 

Objectives 

•  Evaluate,  through  field  testing,  the  reliability  and  performance  of  operating 
a  fiber  optic  tethered  UUV  communication  link.  Determine  what 
performance  can  be  expected  and  how  it  can  be  improved. 

•  Evaluate  the  use  of  fiber  optics  as  a  medium  for  a  simultaneous 
bidirectional  data  link  connecting  the  UUV  to  the  launch  platform. 

•  Provide  real  time  access  to  data  on  either  side  of  the  optical  link  via  custom 
electronics  that  can  interface  easily  to  commercial  equipment. 

•  Provide  a  semi-transparent  split  of  the  system  data  processing  electronics 
(UUV  and  launch  platform)  via  a  bidirectional  data  path  to  the  optics. 

•  Ensure  the  custom  electronics  provides  data  availability  and  integrity. 
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All  the  objectives  listed  above  were  achieved  and  will  be  discussed  in  this 
thesis.  Completion  of  the  objectives  support  the  reliability  and  existence  of  a  fiber 
optic  tethered  UUV,  and  justify  the  further  development  of  this  technology. 
Additionally,  this  communication  system  allows  real  time  data  to  be  processed 
remotely  from  the  vehicle.  The  processing  also  permits  a  more  robust  system  for  the 
remote  equipment  to  accomplish  complex  tasks. 

1.5  Thesis  Summary 

Chapter  2’s  discussion  of  technological  and  space  constraints  will  illustrate 
why  a  fiber  optic  tethered  UUV  was  needed,  and  will  reinforce  the  advantage  of  such 
an  approach.  A  look  at  the  optics  and  payout  fiber  is  included  since  this  represents 
the  basis  for  the  remote  processing.  The  thesis  will  discuss  the  background  of  a 
tethered  UUV  system  and  the  major  components  that  comprise  the  system  and  relate 
to  data  handling  and  routing. 

In  Chapter  3,  the  design  and  configuration  of  the  data  handler  that  is  called  the 
Fiber-Optic  VME  Interface  (FO-VME  I/F)  is  covered.  Its  design  and  development  is 
discussed.  Chapter  4  focuses  on  the  testing  process.  Through  laboratory  and  field 
test  results,  the  entire  system,  and  specifically  the  FO-VME  I/F  and  fiber  optic  link, 
were  tested  thoroughly  to  ensure  reliable  operation.  Important  test  configurations  are 
discussed  and  some  unique  data  analysis  is  provided. 

Chapter  5  discusses  the  newer  technology  and  how  it  can  be  integrated  into 
the  system  to  create  a  more  dynamic  system.  The  system  did  have  a  few  operational 
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errors.  These  are  listed  in  Chapter  6  in  order  to  indicate  the  source  of  each  problem 
and  the  strategies  that  can  or  could  be  used  to  correct  the  problems. 
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CHAPTER  2 

BACKGROUND  &  SYSTEM  OVERVIEW 

Many  of  today’s  research  and  development  programs  rely  on  the  «  ability  of 
a  standard  UUV  test  bed  for  testing.  This  shell  of  a  test  bed  system  is  expanded  and 
modified  to  accommodate  the  recorders,  electronics,  batteries  and  miscellaneous  test 
equipment  that  will  aid  in  the  program’s  objectives.  Modification  and  expansion  is 
not  needed  in  the  fiber  optic  tethered  vehicle,  thus  reducing  UUV  space  and  weight, 
and  restrictions  on  computing  hardware. 

The  advantages  offered  by  the  fiber  optic  tethered  UUV  are  slightly  diminished 
by  the  custom  electronics  required  to  support  the  link.  When  the  link  is  used,  the 
UUV  must  house  the  optical  transmitter  and  receiver  to  drive  the  fiber,  but  it  must 
also  contain  the  electronics  that  interface  with  the  acoustic  array  for  data  and  control, 
plus  to  the  UUV  electronics  for  controlling  UUV  movement  in  the  water.  Topside, 
the  electronics  must  interface  to  the  processing  and  recording  equipment.  Typically 
these  use  industry  standard  interfaces. 

2.1  Necessity  of  a  Fiber  Optic  Tethered  UUV 

There  are  two  major  reasons  why  tethering  of  a  UUV  makes  sense  and  can  be 
beneficial.  They  are  based  on  the  premise  that  the  tether  allows  the  system 
processing  electronics  to  be  relocated  from  the  UUV  to  the  launch  platform.  This 
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relocation  creates  a  space  savings  internal  to  the  UUV  without  the  need  for 
specialized  electronics,  and  permits  the  use  of  virtually  any  size  electronics  equipment 
on  the  dry  side  of  the  tether. 

The  amount  of  electronic  equipment  that  can  go  on-board  a  UUV  is  limited  by 
available  space  and  the  maximum  weight  allowable  for  deployment  of  the  UUV.  The 
constraint  on  space  is  made  worse  by  the  fact  that  a  UUV  is  typically  small,  making 
custom  fit  hardware  the  rule.  The  addition  of  the  fiber  optic  link  partially  removes 
this  constraint.  Most  of  the  added  electronics  can  be  removed  and  placed  on  the 
launch  platform,  leaving  room  for  a  fiber  spool  and  the  associated  optics  and 
electronics.  Also,  the  additional  space  eliminates  the  necessity  of  form-fitting 
hardware  in  the  UUV  and  the  launch  craft  provides  relatively  boundless  space  for 
housing  processing  electronics.  In  addition,  there  is  a  cost  saving  because  the  need 
for  special,  rugged,  or  modified  equipment  is  reduced.  Standard  commercial  products 
can  be  utilized  effectively. 

Besides  the  savings  in  space  within  the  UUV,  the  data  processing  electronics 
on  the  launch  platform  can  now  be  larger  and  more  complex  due  to  the  removal  of 
the  size  constraint.  As  data  processing  computers  evolve,  more  power  is  put  into 
much  more  compact  a  space;  however,  the  high  end  processing  computers,  of  any 
generation,  have  always  been  large.  The  relocation  of  the  processing  computers  from 
the  UUV  to  the  launch  craft  makes  it  possible  to  use  the  best  possible  processor 
(within  budget)  to  meet  the  objectives  of  the  project.  For  example,  the  initial  remote 
processing  system  presented  in  this  thesis  utilized  a  /*VAX  3800  workstation  and  a 
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full  size  15-slot  VME  chassis  for  data  processing  and  command  and  control. 
Including  the  power  supplies  and  fans  needed  for  this  equipment,  this  equals 
approximately  12  ft^  of  computer  equipment.  To  fit  all  of  this  computing  power 
inside  the  UUV  would  add  nearly  six  feet  to  the  UUV’s  length.  At  the  time  this 
system  was  designed  there  were  no  alternatives  that  could  easily  fit  inside  the  UUV. 
The  opportunity  to  place  processing  electronics  on  the  launch  craft  permitted  the  use 
of  standard,  unmodified  laboratory  equipment  for  remote  processing. 

2.2  Tethered  UUV  Subsystems 

Figure  2. 1  shows  the  main  subsystem  blocks  needed  to  create  a  tethered  UUV 
system.  There  are  four  unique  susbsystems  that,  when  combined,  form  a  system 
capable  of  remotely  processing  UUV  data  and  controlling  UUV  actions.  The 
subsystems  are  a)  fiber  optics,  b)  UUV  electronics,  c)  launch  platform  processing 
electronics  and  data  recording,  and  d)  data  handling  and  routing  electronics.  The 
following  sections  discuss  each  subsystem  block. 

2.2.1  Fiber  Optic  Link 

An  objective  of  a  previous  fiber  optic  link  study  was  to  prove  that  a  reliable 
connection  could  be  maintained  between  a  UUV  and  a  launch  platform  [7,  8].  The 
objective  was  established  for  long  fiber  lengths  and  high  UUV  speeds.  The  success 
of  this  study  provided  a  strong  impetus  for  the  use  of  fiber  optics  used  for  remote 


Figure  2.1  PRINCIPAL  BLOCKS  OF  4  TETHERED  UUV 
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control  and  command  processing,  and  for  continued  research  into  optically  tethered 
UUVs. 

The  original  fiber  optic  link  used  in  the  above  study  was  designed  to  utilize; 

•  1300  nm  and  1550  nm  wavelengths  to  provide  simultaneous  bidirectional 
optical  communication 

•  a  dispersion  shifted,  single  mode  fiber 

•  fiber  lengths  of  5  Km  to  20  Km 

•  commercially  available  parts 

•  a  16  MHz  data  rate 

•  modular  and  upgradeable  components 

Because  of  the  low  data  rate,  dispersion  was  not  of  concern  and  the  design  was 
centered  around  the  flux  budget.  The  flux  budget  represents  the  total  attenuation 
experienced  from  transmitter  to  receiver.  Using  the  maximum  attenuation  ratings  for 
all  the  components,  a  system  loss  of  greater  than  30  dBm  was  calculated  [9,  10]. 
Figure  2.2  is  the  block  diagram  of  this  communication  scheme  and  Table  2.1  lists  all 
of  the  components  used  with  optical  and  mechanical  parameters.  The  component 
selection  did  not  change  dramatically  for  the  new  system  built  around  remote 
processing.  Similar  optical  devices  were  used  but  were  packaged  in  less  than  half  the 
space.  Parameters  and  tradeoffs  that  drive  this  optical  tether  design  are  data  rate, 
cost,  UUV  capacity,  distance,  deployment  cost,  and  repair  frequency  [3,  11,  12]. 


TRANSMITTER 

1300nn 


ELECTRONIC  DATA  HANDLER 
AND  ROUTER 


ELECTRONIC  DATA  HANDLER 
AND  ROUTER 


Figure  2.2  FIBER  OPTIC  BLOCK  DIAGRAM 
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TABLE  2.1 

OPTICAL  COMPONENTS 


Component 

Manufacturer 

Part  # 

Parameters 

Tx/Rx  Pair 
1300  nm 

Laser  Diode 

LDDL-2510 

Poui=  -6  dBm 

Rx  Sensitivity  -43  dBm 

Data  Rate  =  20  Mbps 

Manchester 

Tx/Rx  Pair 
1550  nm 

Laser  Diode 

LDDL-2515 

Pou,=  -9  dBm 

Rx  Sensitivity  =  -43  dBm 

Data  Rate  =  20  Mbps 

Manchester 

WDM 
(1300  mux/ 
1550  demux) 

JDS  Fitel 

WD1315-X-A2 

loss  <  .8dB 

demux  isolation  >  45  dB 
back  reflection  <  -40  dB 

WDM 
(1550  mux/ 
1300  demux) 

JDS  Fitel 

WD1315-Y-A2 

loss  <  .8  dB 

demux  isolation  >  45  dB 

back  reflection  <  -40  dB 

Fiber 

Coming 

SMF/DS 

CPC3  (with 
reinforcement) 

Attenuation  0.21  dB/Km  typical 
Diameter  800^m 

Weight  2.2  Ibs/km  air 

Tensile  Strength  100  lbs  ultimate 
30  lbs  working 
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2.2. 1.1  Transmitter/Receiver  (Tx/Rx)  Pair 

To  accommodate  the  requirement  for  long  data  link,  a  distributed  feedback 
laser  (DFB)  was  selected.  Its  small  FWHM  added  a  margin  of  safety  against 
dispersion  problems  that  were  not  necessarily  of  concern  because  of  the  low  data  rates 
used.  Overall  the  Tx/Rx  pairs  were  over  specified  to  compensate  for  uncertainty  in 
attenuation  fluctuations  due  to  fiber  payout.  The  DFB  lasers  chosen  are  readily 
available  commercial  parts  and  were  purchased  as  a  pair  for  each  wavelength  used, 
1300  nm  and  1550  nm. 

The  Tx/Rx  components  provide  a  full  function,  high-speed  fiber  optic  link. 
Both  operate  at  NRZ  rates  of  up  to  500  Mbytes/ sec.  Our  application  was  16 
Mbytes/sec  and  the  components  were  tuned  for  that  frequency.  Data  I/O  for  each  is 
ECL  lOK  compatible.  The  Tx  module  incorporates  circuitry  for  monitoring  and 
controlling  the  optical  power  and  temperature.  The  optical  receiver  employs  a 
temperature  compensated  Ge-APD  (Avalanche  Photo  Diode)  which  provides  the  high 
sensitivity  required.  Additionally,  the  Rx  incorporates  automatic  gain  control  (AGC) 
which  enables  operation  over  a  wide  range  of  optical  loss  budgets. 

2.2. 1.2  Wavelength  Division  Multiplexers 

To  operate  the  bidirectional  link  simultaneously,  a  different  light  wavelength  is 
transmitted  in  each  direction  along  the  fiber.  A  wavelength  division  multiplexer 
(WDM)  injects,  extracts,  and  isolates  outgoing  and  incoming  wavelengths  over  a 
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single  fiber.  Additionally  it  isolates  the  light  signals  between  the  local  transmitter  and 
receiver.  Features  of  the  WDMs  include: 

•  bidirectional  transmission  with  greater  than  80  dB  directivity 

•  wide  spectral  channels  for  use  with  Fabry  Perot  or  DFB  lasers  without  tiglit 
wavelength  selection  or  control 

•  less  than  -40  dB  back  reflection. 

2.2.1.3  Payout  Fiber 

In  the  past,  remote  underwater  systems  have  had  a  communication  bottleneck. 
Acoustic  communication  transmitted  through  the  water  eliminates  fiber  problems,  but 
is  severely  limited  by  bandwidth  and  real  time  data  availability.  An  expendable  FO 
link  based  on  a  small  diameter  cable  offers  the  best  trade-off  for  this  application  [6]. 
An  optimally  designed  cable  incorporates  single  mode  fiber  with  minimal  diameter 
growth  over  wire.  Fiber  is  relatively  inexpensive,  reliable,  has  high  bandwidth  and 
can  support  bidirectional  communication  over  great  distances  [13,  14].  Features  of 
the  payout  fiber  used  include; 

•  inexpensive  in  production  quantity 

•  low  attenuation;  <  0.5  dB/km  @  1300  nm  and  1550  nm  wavelengths 

•  high  tensile  strength;  100  lbs  ultimate;  30  lbs  working 

•  anti-abrasion  jacket 
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•  continuous  length  up  to  20  km 

•  small  bend  radius  and  excellent  optical  performance  at  1550  nm  because  of 
dispersion  shifted  properties 

•  tolerance  to  temperature  and  pressure  fluctuations 

2.2.2  Underwater  Vehicle  Subsystem 

Figure  2.3  shows  the  UUV  system  layout  and  configuration.  The  forward 
section  of  the  UUV  generally  consists  of  the  system  specific  hardware  of  a  particular 
project,  while  the  aft  section  of  the  UUV  contains  the  mechanics  that  comprise  the 
UUV.  The  first  section  is  the  acoustic  array  with  a  small  ballast  section,  followed 
immediately  by  the  electronics  section. 

Within  the  electronics  section  are  battery  packs  to  power  acoustic  transmits, 
acoustic  array  electronics,  and  the  interface  unit.  In  the  upper  forward  companment, 
the  interface  unit  resides,  this  is  made  up  of  a  VME  chassis  containing  six  circuit 
boards,  three  commercial,  and  three  custom  designs.  One  card  contains  all  of  the 
optical  components  for  communication.  This  is  also  the  unit  that  is  responsible  for 
the  data  handling  and  routing  and  is  discussed  in  detail  in  chapter  3.  In  general,  the 
batteries  provide  energy  for  approximately  thirty  minutes  of  testing;  however,  in  the 
laboratory,  bench  power  supplies  can  be  substituted  for  continuous  testing  and 
troubleshooting. 

The  propulsion  batteries  and  the  fiber  optic  (FO)  cable  section  are  located 
behind  the  electronics  section.  The  battery  section  is  composed  of  a  large  bank  of 
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silver-cell  batteries  that  are  required  for  propulsion  and  maneuverability  of  the  UUV. 
The  FO  cable  section  houses  a  pressure  vessel  that  holds  the  spool  of  FO  cable.  This 
vessel  is  flooded  while  the  UUV  is  submersed.  This  optical  link  design  connects  the 
fixed  end  of  the  FO  cable  to  a  pressure  penetrator  leading  to  the  optics  on  the  dry 
side  of  the  UUV  and  allows  the  other  end  to  freely  payout  from  the  pressure  vessel 
through  the  remaining  sections  of  the  UUV  exiting  from  the  top  stabilizer  fin  at  the 
aft  most  section. 

Next  is  the  control  section  that  contains  the  autopilot,  motion  sensors,  and 
electronics  for  UUV  control.  Two  electrical  links  exist  between  the  autopilot  and  the 
interface  unit  and  from  the  autopilot  to  the  transmitter  battery  box.  These  links 
provide  system  independence  and  are  the  only  two  electrical  connections  between  the 
UUV  test  bed  and  unique  system  electronics  and  are  dedicated  to  test  initiation  and 
safety.  Finally,  aft  of  the  control  section  is  the  UUV  afterbody  which  consists  of  the 
motor  and  propulsion  mechanics. 

2.2.3  Launch  Platform  Subsystem 

The  remote  subsystem  residing  on  the  platform  has  two  configurations.  The 
configuration  in  use  today  encompasses  the  functionality  of  the  original;  however, 
because  the  original  configuration  was  used  for  such  extensive  data  collection,  it  will 
be  discussed  briefly.  The  original  subsystem  was  used  for  remote  control  of  the  UUV 
in  the  initial  field  tests.  A  block  diagram  of  this  entire  system  is  shown  in  figure  2.4. 


m 

CO 

(0 

U 


Ed 

s 

> 


Figure  2.4  REMOTE  COMMAND  &  CONTROL  CONFIGURATION 
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The  original  subsystem  on  the  launch  craft  contained  two  ruggedized  units. 

One  unit  contained  the  piVAX,  which  is  the  control  computer,  and  two  optical  disk 
recorders,  one  used  for  startup  and  recording  of  control  data,  and  another  used  to 
store  raw  data.  The  second  unit,  a  VME  chassis,  contained  an  interface  unit  and 
three  additional  raw  data  optical  disk  recorders.  The  launch  platform  interface  unit 
contained  the  optical  transmitter  and  receiver  complementary  to  those  within  the  UUV 
and  is  connected  to  the  other  end  of  the  FO  link.  A  monitor  is  also  included  for 
viewing  the  vehicle  parameters  such  as  position  and  speed. 

Figure  2.5,  in  a  similar  manner,  portrays  a  remote  processing  system  that  was 
tested  in  late  1992  and  early  1993.  The  new  remote  processing  setup  replaces  both 
ruggedized  chassis  with  one  ruggedized  VME  chassis  containing  a  ^VAX  on  a  VME 
card,  and  a  personal  computer  as  an  interface  for  human  intervention.  Although  the 
system  is  now  configured  to  accommodate  real  time  remote  processing  of  data,  simple 
tests  requiring  only  remote  control  of  the  UUV  and  no  intervention  can  still  be 
performed.  In  either  subsystem,  remote  control  or  remote  processing,  the  UUV 
configuration  remains  unchanged. 

2.2.4  Interface  Unit 

The  functionality  of  a  tethered  system  lies  within  the  interface  unit  (lU).  The 
lU,  in  its  different  configurations,  controls  the  interfacing  of  several  hardware 
components  within  the  system.  These  components  are  the  acoustic  array  and  the 
autopilot  in  the  UUV  and  the  tactical  computer  and  the  optical  drive  located  on  the 
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launch  craft.  In  addition  to  its  interfacing  responsibilities,  the  lU  maintains  the  fiber 
optic  communication  link  between  the  launch  platform  and  the  UUV  lU.  The  system 
on  the  launch  platform  also  contains  two  vector  processing  boards  that  handle  the 
signal  processing  tasks. 

The  following  sections  introduce  the  boards  and  the  interface  unit 
configurations.  For  this  thesis,  the  board  of  particular  interest  is  the  Fiber  Optic 
VME  Interface  (FO  VME  I/F).  This  board  is  responsible  for  bridging  the  VME 
based  systems  on  either  side  of  the  optical  link.  The  design  of  the  FO  VME  I/F  will 
be  discussed  in  detail  in  chapter  3. 

2.2.4. 1  Interface  Unit  Board  Definitions 

Each  board  within  the  lU  has  a  specific  function  and  was  designed  or 
purchased  to  meet  those  unique  requirements.  Table  2.2  lists  the  boards  and  some  of 
their  technical  highlights. 
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TABLE  2.2 

INTERFACE  UNIT  BOARD  HIGHLIGHTS 


Board  Name 

Model  ^/Manufacturer 

Highlights 

VME 

Controller/Main 

Processor 

PME68-33/Radstone 

25  MHz  68030  CPU 

VSB  Interface 

40  MBytes/ sec  Data  Transfers 

Ethernet 

ENET-  1/Radstone 

25  MHz  68020  CPU 

Ethernet  2.0  Interface 

Thin  Wire  Interface 

Fiber  Optic  Tx/Rx 

Custom 

Bidirectional  Optical  Interface 

16  MBits/ sec.  Optical  Data  Rate 
Sync  Detection 

Fiber  Optic  VME 
Interface 

Custom 

Double  Buffered  Memories 
Supports  32-Bit  Block  Transfers 
at  25  MBytes/sec. 

SCSI-1 1 

SCSI-1 1/Radstone 

25  MHz  68020  CPU 

SCSI  Interface  at  5  MBytes/sec. 
VSB  Interface 

Array  Processor 

Supercard/CSPI 

40  MHz  i860  RISC  Processor 

66  MFLOPS 

NTDS 

NTDS  Type  C/G.E.T. 

8  MHz  68000  CPU 

Full  Duplex  Interface  Between 
VME  and  Peripheral 

Raw  Data  Interface 

Custom 

Double  Buffered  Memories 
Supports  32-Bit  Block  Transfers 
at  25  MBytes/sec. 

(iWAX 

KAV-30AD/DEC 

20  MHz  rtVAX300  Processor 
VME  Interface 

VAXELN  runtime  environment 
2.7  VUPS  (VAX  Processing 
Units  Per  Second) 

2.2.4.2  Configurations 

There  are  three  different  configurations  of  the  lU  in  the  remote  system.  The 
launch  platform’s  lUs,  configurations  A  &  B  and  the  UUV  lU  configuration  C  are 
listed  below  in  Table  2.3. 


TABLE  2.3 

VME  CHASSIS  CONFIGURATIONS 


Remote  Control 
Subsystem  - 1991 

Main  Processor 
Ethernet 

Fiber  Optic  Tx/Rx 

Fiber  Optic  VME 
Interface 


Remote  Processing 
Subsystem  -  1992,93 

Main  Processor 
Ethernet 

Fiber  Optic  Tx/Rx 

Fiber  Optic  VME 
Interface 


UUV  Subsystem 

Main  Processor 
Ethernet 

Fiber  Optic  Tx/Rx 

Fiber  Optic  VME 
Interface 


SCSI-1 1 


(iWAX 

(2)  Array  Processors 


Raw  Data  Interface 
NTDS  Type  C 
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CHAPTER  3 

DESIGN  OF  THE  HBER-OPTIC  VME  INTERFACE 


The  design  of  the  Fiber-Optic  VME  interface  (FO-VME  I/F)  splits  one  VME 
backplane  into  two  distinct  backplanes.  The  two  backplanes  are  often  located  many 
kilometers  apart,  but  can  communicate  through  the  FO-VME  I/F  and  over  the  optical 
link  to  share  real  time  information.  This  integral  board  in  the  system’s  interface  unit 
is  extremely  crucial  for  the  success  of  the  fiber  optic  link.  It  allows  the  link  to 
operate  at  a  high  data  rate  while  keeping  the  data  accessible  on  an  industry  standard 
VME  backplane.  Without  the  development  of  the  FO-VME  I/F  board,  interfacing  to 
powerful  commercial  electronics  necessary  on  either  side  of  the  link  could  have 
proved  to  be  a  more  difficult  task.  A  multitude  of  interfaces  (ie.  NTDS,  Ethernet, 
and  SCSI)  are  required  to  have  access  to  the  interface  units  located  at  the  opposite 
ends  of  the  link.  The  FO-VME  I/F  provides  a  common  point  for  data  transfers  and 
does  not  require  customized  interfacing  among  separate  modules.  Figure  3.1  is  a 
functional  block  diagram  of  the  FO-VME  I/F  board  and  provides  a  reference  to 
functions  discussed  throughout  the  chapter. 

3.1  Design  Goals  and  Objectives 

The  objectives  stated  in  chapter  1  are  system  oriented  goals  and  are  meant  to 
disclose  where  the  FO-VME  I/F  fits  into  system  success.  When  these  objectives  are 
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FIBER-OPTIC  VME  INTERFACE  BLOCK  DIAGRAM 
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translated  into  hardware  design,  they  allow  the  designer  to  understand  what  steps  are 
needed  to  accomplish  system  requirements  within  one  part  of  the  system. 

3.1.1  Physical  Constraints 

The  interface  unit  resides  in  two  locations,  the  UUV  and  the  launch  platform, 
with  the  UUV  being  the  more  physically  restricting  of  the  two.  Because  of  the  UUV 
size  constraint  and  the  need  for  conformance  at  the  two  locations,  the  UUV 
restrictions  drove  the  design  on  both  sides.  Even  thought  the  launch  craft  presented 
no  space  restrictions,  it  was  designed  with  UUV  requirements  for  several  reasons:  a) 
hardware  could  be  swapped  between  UUV  and  launch  platform  interface  units  with  no 
modifications,  b)  portions  of  the  interface  unit  could  be  integrated  into  one  unit  before 
adding  the  communication  link  and,  c)  only  one  custom  hardware  version  was  needed 
to  be  built  instead  of  specific  versions  for  the  UUV  and  launch  platform. 

The  size  constraint  aboard  the  UUV  posed  another  problem,  lack  of 
redundancy.  Data  transmitted  within  the  UUV  and  especially  up  the  link,  was 
vulnerable  to  corruption.  In  addition,  any  complete  failure  of  a  component  or  board 
could  terminate  a  successful  test.  The  lack  of  redundancy  in  the  system  was 
compensated  for  in  two  different  fashions.  Designs  were  integrated  into  the  FO-VME 
I/F  board  that  included  an  overriding  control  by  the  user.  This  meant  that  a  fatal 
error  could  be  averted  by  resetting  and  reconfiguring  the  board.  Also  through  the  use 
of  status  registers,  anomalies  could  be  identified  and  recorded.  In  the  case  of  a  fatal 
error,  an  organized  and  safe  system  shutdown  would  occur. 
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The  second  attempt  to  compensate  for  no  redundancy  was  by  extensive  testing 
for  reliability.  As  will  be  shown  in  chapter  4,  thorough  testing  of  the  boards  and 
eventually  the  system,  were  performed  to  significantly  decrease  the  chance  of  a 
system  error  during  actual  testing.  This  method  of  testing  proved  worthwhile  by 
exposing  problems  early  in  the  design. 

3.1.2  Data  ReUability 

When  data  is  transferred  over  the  VME  backplane,  it  is  assumed  that  transfers 
will  be  made  reliably.  This  is  true  for  the  VME  backplane  since  it  is  a  proven  and 
tested  standard  that  has  succeeded  in  the  electronics  community.  For  the  design  of 
the  FO-VME  I/F  board,  this  same  data  reliability  was  needed.  Reliability  should  be 
expected  when  good  electronic  design  practices  are  followed.  Again,  through  the  use 
of  comprehensive  tests,  known  data  patterns  can  travel  through  the  entire  system,  thus 
verifying  system  and  FO-VME  I/F  reliability. 

3.1.3  Testability 

For  board  level  and  system  testing,  the  FO-VME  I/F  is  required  to  have  a 
testable  design.  At  the  board  level,  this  translates  to  well  placed  components  and 
signal  traces  that  are  accessible  for  instrumentation  during  troubleshooting.  Also, 
simple  VME  control  was  placed  on  the  board  that  could  put  the  board  into  different 
modes  depending  on  the  tests  performed.  Finally,  the  use  of  status  registers  allowed 
for  monitoring  during  use  and  for  the  isolation  of  problem  areas. 
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3.1.4  Compatibility 

Because  the  function  of  the  card  is  to  bridge  the  VME  bus  to  a  fiber  optic 
transmitter,  both  sides  must  be  well  defined.  The  board  is  designed  to  be  compliant 
with  VMEbus  specification  ANSI/IEE  STD  10 14- 1987  lEC  821  and  297.  This 
specification  is  distributed  by  VITA,  VMEbus  International  Trade  Association. 
Compatibility  with  this  specification  makes  the  FO-VME  I/F  compatible  with  all  other 
VME  products  using  this  specification. 

The  serial  channel  to  the  optics  must  also  be  compatible  with  the  data  rate, 
format,  and  electrical  levels  needed  for  the  transmitter  and  receiver  circuit.  The 
design  permits  the  use  of  newer  optical  components  for  future  upgrades. 

3.1.5  Data  Availability  and  Integrity 

The  need  for  data  in  real  time  adds  the  need  for  data  availability.  The  delay 
that  could  be  added  to  transmitted  data  had  to  be  minimized.  Design  of  the  FO-VME 
I/F  board  incorporates  double  buffering  of  transmitted  and  received  data  to  permit 
continuous  and  uninterrupted  use  of  the  optical  link.  When  data  is  made  available,  it 
is  transmitted  in  a  continuous  bit  stream  with  no  data  gaps.  The  double  buffering 
permits  the  interface  controller  to  transmit  or  receive  data  on  one  buffer  while  the 
opposite  function  is  simultaneously  occurring  without  the  need  of  controller 
assistance.  The  VME  controller  determines  data  priority  for  real  time 
communications  with  the  interface  unit  on  the  other  side  of  the  link.  This  scheme 
grants  complete  data  availability  to  the  user. 


Integrity  also  occurs  because  the  VME  controller  is  left  out  of  the  transmission 
except  when  needed.  Data  is  accessed  from  the  FO-VME  I/F  at  a  rate  12.5  times 
faster  than  the  optical  link.  This  means  to  sustain  the  link  at  maximum  bandwidth, 
the  controller  only  dedicates  8%  of  its  time  for  service  of  the  FO-VME  I/F  board. 

3.2  The  VME  Bus 

In  1981,  the  VME  bus  was  made  available  to  the  electronics  community.  Its 
design  was  started  years  earlier  and  was  meant  to  provide  a  solid  16/32  bit  bus 
standard  that  would  be  monitored  by  an  independent  organization  [15].  The  initial 
players  in  the  game  were  Motorola,  Phillips/Signetics,  and  Mostek.  Their  efforts 
created  one  of  the  most  commonplace  bus  structures  used  today. 

3.2.1  Mechanical  Benefits 

As  stated  earlier,  the  placement  of  electronics  inside  the  UUV  imposed  a  size 
restriction  on  their  design.  The  actual  usable  space  varied  as  the  system  design 
progressed,  but  the  goal  of  a  compact  electronics  package  remained  strict.  Other  bus 
structures  considered  for  their  size  and  popularity  were  the  STD  Bus,  IBM-PC  Bus, 
and  Multibus.  However,  some  of  the  mechanical  attributes  of  these  alternate  busses 
pose  problems.  The  dimensions  of  both  the  IBM-PC  Bus  ana  Multibus  are  too  large. 
The  IBM-PC  Bus,  though  smaller  in  area  than  the  VME  bus  card,  has  a  length  that 
makes  it  awkward  to  fit  it  into  the  allotted  area.  Another  problem  involves  the  use  of 
copper  fingers  for  connection  to  the  backplane  as  opposed  to  the  pin  and  socket 
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connection  used  by  VME.  The  copper  finger  arrangement  does  not  make  as  good  of 
a  connection  and  degrades  more  quickly  over  time  especially  as  the  card  is  removed 
and  replaced. 

An  advantage  offered  by  all  of  the  bus  structures  is  mechanical  modularity. 
Since  each  board  is  designed  to  a  standard,  it  can  be  placed  and  used  in  any  system 
utilizing  that  standard.  This  modularity  extends  from  standard  board  dimensions  to 
connector  pinouts.  Table  3.1  [15]  shows  a  comparison  of  the  bus  structures 
considered  for  this  subsystem  along  with  other  popular  choices. 

3.2.2  Electronic  Benefits 

Besides  its  excellent  mechanical  attributes,  VME  is  also  an  excellent  electronic 
choice.  This  long  standing  and  well  supported  bus  structure  offers  a  high  data  speed 
backplane.  The  backplane  functions  at  a  variety  of  data  widths  (8,  16,  24,  and  32 
bits)  and  address  widths  (16,  24,  and  32  bits).  When  operating  at  the  full  data  bus 
width  of  32  bits,  a  theoretical  transfer  speed  of  40  MBytes/ second  is  possible  [16]. 
Most  applications  will  fall  short  of  this  limit,  but  can  still  easily  achieve  speeds  in 
excess  of  30  MBytes/sec.  Table  3.2  [15]  lists  features  of  the  VMEbus  standard. 

In  order  to  achieve  such  data  rates,  the  backplane  must  be  electrically  sound. 
Years  of  refinement  have  developed  a  backplane  that  is  both  immune  to  modest 
external  noise  levels  as  well  physically  designed  to  prevent  excessive  crosstalk 
between  traces  when  functioning  at  high  speeds. 


Table  3.1  FEATURES  OF  SYSTEU  BUSSES 
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Table  3.2  VMEBUS  FEATURES 


Item 

Specification 

Architecture 

Master/slave 

Transfer  mechanism 

Asynchronous, 
non-multiplexed, 
opt  multiplexed  (t) 

Addressing  range 

16-bit  (short  I/O) 

24-bit  (standard) 

32-lat  (extended) 

64-bit  (long)  (t) 

Datapath  width 

8. 16. 24  or  32-bit 
64-bit  (t) 

Unaligned  data 
transfers 

Yes 

Error  detection 

Yes 

Data  transfer  rate 

0-40  Mbyt^sec 

0-80  Mbyte/sec  (t) 

Interrupts 

7  levels 

Multiprocessing 

capability 

1  -  21  processors 

System  diagnostic 
capability 

Yes 

Mechanical  standard 

Single  height 

Double  height 

International  standards 

Yes 

No  cenml  synchronizaiion 
dock 


Address  tange  sdected 
dynamicaUy 


Data  path  width  selected 
dynamically 


Compatible  with  most 
lar 


Using  BERR*  (optional) 


Priority  interrupt  system 
with  STATUSAD 


Flexible  bus  arbitration 


Using  SYSFAIL*  (optional) 


160  X 100  mm  eurocard 
160  X  233  mm  eurocard 
DIN  603*2  connectois 


me  821,  IEEE  1101 
JEEE  1014 


(t)  Denotes  proposed  VMEbus  enhancement 
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Finally  there  is  the  issue  of  independence  among  VME  modules  in  a  common 
backplane.  The  bus  functions  only  when  information  is  transferred  among  modules 
and  will  not  inhibit  their  independent  functions.  A  VME  module  can  process  data  or 
interface  to  an  external  device  at  any  speed  without  using  the  backplane.  A  functional 
block  diagram  of  the  VMEbus  architecture  is  shown  in  figure  3.2  [15]. 

3.3  Design 

After  it  was  determined  where  the  FO-VME  I/F  board  would  fit  in  the  system 
layout,  some  design  issues  were  resolved.  A  list  of  electronic  requirements  was  made 
to  guide  the  design.  These  requirements  had  to  provide: 

•  slave  compatibility  with  the  VME  interface  specification 

•  32  bit  wide  data  block  transfers  over  the  backplane 

•  a  serial  transmit  stream  to  optical  transmitter  in  a  Manchester  encoded 
format 

•  reception  of  a  serial  data  stream  from  the  optical  receiver 

•  double  buffering  for  transmitted  and  received  data  so  that  both  could 
function  independently  and  simultaneously 

•  flexibility  in  board  addressing  and  interrupt  levels 

•  status  registers  that  could  be  monitored  to  ensure  proper  board  functioning 

•  a  writable  register  for  dynamic  board  control 
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Figure  3.2  VMEBUS  BLOCK  DIAGRAM 
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3.3.1  VME  Interface 

The  FO-VME  I/F  interface  to  the  VME  consists  of  the  Cypress  VIC068  chip 
and  its  transceivers  [17].  The  VIC068  is  a  complete  VME  interface  that  adheres  to 
the  VME  specification  revision  C.l.  The  VME  interface  is  simplified  with  the  use  of 
this  chip,  but  because  of  the  VIC068  complexity,  there  is  a  learning  curve  before  its 
use  will  pay  off.  The  VIC068  is  a  programmable  interface  and  must  be  initialized 
upon  power  up  for  proper  operation  for  its  specific  application.  One  of  the  most 
difficult  aspects  of  using  the  VIC068  is  that  it  needs  a  64  MHz  clock  to  achieve  its 
full  potential.  Although  a  clock  speed  of  this  frequency  can  often  cause  crosstalk 
problems,  this  high  frequency  was  handled  delicately  during  PCB  layout  and  no 
problems  were  identified. 

The  final  design  that  centered  around  the  VIC068  achieved  data  rates  of  25 
MBytes/second  across  the  backplane  when  performing  block  transfers.  This  data  rate 
is  more  than  adequate  for  servicing  the  optical  link  and  does  not  provide  a  significant 
burden  on  the  main  controller  in  the  backplane.  In  other  words,  it  allows  the  link  to 
operate  continuously  at  16  MBits/second  while  not  requiring  a  large  percentage  of  the 
VME  controller’s  time  for  maintenance 

3.3.2  Data  Formats 

3.3.2. 1  Link  Data  Format 

The  serial  data  transmitted  on  the  link  is  encoded  into  a  Manchester  format.  A 
Manchester  format  for  serial  data  involves  the  mixing  of  the  data  and  the  clock  at  the 
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source  so  that  both  can  be  recovered  at  the  receiver.  Figure  3.3  displays  how  binary 
data  is  encoded  to  form  Manchester  data.  As  shown  in  the  figure,  the  Manchester 
data  contains  a  transition  in  the  middle  of  every  data  cell  that  is  extracted  to  form  a 
clock  when  the  data  in  decoded.  Also,  consecutive  I’s  or  O’s  show  up  as  a  clock  thus 
providing  constant  transitions  and  an  indication  that  the  link  is  active.  One  benefit  of 
this  form  of  encoding  is  that  the  clock  can  be  recovered  and  used  for  the  clocking  of 
the  data  through  the  rest  of  the  design.  Because  the  link  is  a  connection  between  two 
independent  subsystems,  it  can  not  be  guaranteed  that  they  are  using  precisely  the 
same  clocking  frequency  or  that  the  clocks  are  in  phase.  Once  received  data  is 
recovered  and  stored,  it  can  be  reclocked  out  at  the  local  subsystem’s  clock  rate. 

Another  benefit  for  Manchester  encoding  is  the  transmitted  data  is 
continuously  transitioning.  Each  data  cell  contains  a  data  transition  which  makes  it 
simple  to  determine  whether  or  not  the  link  is  active  by  the  appearance  of  data 
transitions  even  when  communications  are  idle. 

A  disadvantage  to  Manchester  encoding  is  that  the  entire  link  bandwidth  is 
needed  for  this  transmission.  As  figure  3.3.  shows,  the  actual  data  needed  to  be 
transmitted  is  half  the  frequency  of  the  Manchester  encoded  data.  In  other  schemes 
such  as  NRZ  (non  return  to  zero),  the  data  does  not  contain  clock  data  and  thus  runs 
at  half  the  bandwidth.  NRZ  encoding  can  double  the  available  bandwidth  of  the  serial 
link.  However,  NRZ  is  difficult  to  synchronize  because  of  its  non-periodic 


transitions. 
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The  actual  serial  data  format  is  shown  in  figure  3.4.  Each  packet  takes  16.384 
ms  for  transmission,  where  4  us  are  required  for  link  synchronization.  Serial  packets 
can  occur  non-stop  and  can  utilize  100%  of  the  link  bandwidth.  Data  packets  can 
also  be  transmitted  at  a  much  slower  pace  from  transmit  buffer  to  receive  buffer,  but 
the  link  always  operates  at  16  MHz. 

3.3.2.2  Buffer  Packet  Format 

Each  individual  transmit  and  receive  buffer  on  the  FO-VME  I/F  board  is  32 
kbytes  in  size,  organized  8k  x  32  bits.  Selection  was  made  on  the  32  bit  data  width 
for  ease  in  interfacing  to  the  VME  data  path  without  the  need  for  additional 
demultiplexing.  Also,  the  size  of  the  memory  integrated  circuit,  an  88  pin  slim  DIP 
package,  occupies  very  little  board  space.  The  buffer  size  is  known  as  the  principal 
data  packet  and  contains  the  formatted  data  for  every  transmission  on  the  link.  Figure 
3.5  shows  the  breakdown  of  the  contents  of  a  principal  data  block.  Its  division 
allocates  specific  portions  for  raw  acoustic  data  and  control  data  (primarily  ethemet 
data).  Also  a  preamble  is  used  that  contains  a  user  defined  64  bit  sync  word  that, 
when  decoded,  indicates  the  start  of  a  principal  block. 

Although  the  same  format  is  used  for  either  direction  on  the  link,  not  all  the 
allotted  areas  will  always  be  used.  For  example,  there  is  no  raw  acoustic  data  that  is 
passed  from  the  launch  platform  to  the  UUV;  that  portion  of  the  principal  block  can 
be  ignored  even  though  it  is  still  transmitted.  It  is  also  not  required  to  be  read  by  the 
controller  when  received  in  the  receive  buffer. 


PREAMBLE 
(256  BYTES) 


3.5  PRINCIPAL  BLOCK  DATA  FORMAT 
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3.3.3  FO-VME  I/F  Memory  Map 

All  modules  present  in  a  VME  baclqjlane  are  configured  to  occupy  a  specific 
address  range.  In  a  VME  system,  there  are  multiple  address  ranges,  each 
representing  the  number  of  address  bits  and  data  bits  being  used  [16].  For  example, 
A32/D32  in  a  VME  system  means  that  a  board  will  respond  with  32  bit  data  to  data 
requests  that  require  32  address  bits.  Figure  3.6  is  a  memory  map  of  the  FO-VME 
I/F  board.  It  shows  the  selectable  A16/D8  and  A32/D32  address  space  on  this  board 
and  what  is  contained  in  these  ranges  if  they  are  accessed.  It  is  important  that  the 
address  ranges  are  selectable  because  different  VME  controllers  cannot  always  access 
any  VME  location  at  a  given  VME  address  and  data  width.  For  example,  a  controller 
may  only  perform  A32/D32  transfers  in  the  lower  half  of  VME  space,  therefore  a 
board  would  need  to  be  set  for  an  acceptable  address  in  that  range. 

3.3.4  Optical  Tx/Rx  Interface 

One  function  of  the  FO-VME  I/F  board  is  to  interface  with  the  optical 
transmitter  and  receiver.  As  stated  earlier,  the  serial  data  interface  is  Manchester 
encoded  before  transmission  on  the  fiber,  and  it  is  the  function  of  the  FO-VME  I/F  to 
provide  the  encoding  and  decoding. 

The  task  is  accomplished  easily  since  a  high  clock  frequency  of  64  MHz 
resides  on  the  board.  The  encoding  is  simply  the  ’exclusive  NOR’  of  a  16  MHz 
clock  and  the  data,  re-clocked  at  32  MHz  for  stability.  Decoding  is  simpler  yet  with 
the  use  of  a  commercial  Manchester  decoder. 
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figure  3.6  FO-VME  I/F  MEMORY  MAP 
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Data  on  the  FO-VME  I/F  is  handled  as  32  bit  words  and  translated  to  serial 
for  interfacing  with  the  optics.  Figure  3.7  steps  through  the  serial  data  to  buffer 
storage  routine.  Manchester  encoded  data  is  decoded  and  translated  to  16  bit  words. 
In  this  form  it  is  stored  in  32  bit  wide  locations  in  memory.  When  a  new  sync  is 
decoded,  the  present  buffer  is  no  longer  written  and  is  marked  as  full. 

3.3.5  Dual  Double  Buffer  Memories 

Each  buffer  on  the  FO-VME  I/F  board  is  a  8k  x  32  bit  RAM.  Separate  I/O  is 
provided  for  independent  input  and  output  connections.  The  same  address  lines  are 
used  for  both  the  read  write  functions,  thus  simultaneous  reads  and  write  are  not 
possible.  The  board  has  two  banks  of  memory,  transmit  and  receive  and  each  is 
operated  independently  from  the  other;  data  can  be  received  by  the  board  while  the 
VME  controller  is  transmitting  data.  Each  bank  is  comprised  of  two  memories  and 
they  are  in  the  same  location  in  VME  address  space.  When  the  controller  completes 
the  writing  of  a  transmit  buffer,  it  can  continue  to  write  the  next  block  in  the  same 
address  space.  It  appears  to  the  controller  as  if  it  is  writing  over  the  previous  data, 
but  in  fact  it  is  writing  the  next  transmit  buffer  while  the  first  one  is  being  transferred 
to  the  optics  for  transmission  over  the  fiber.  Overall,  the  toggling  of  memories  is 
transparent  to  the  user.  A  similar  scenario  happens  on  the  receive  side  where  the 
VME  controller  can  be  reading  received  data  while  the  second  receive  buffer  is 
reading  data  from  the  optical  receiver.  This  function  of  toggling  memories  makes  the 
card  simple  to  use  and  easy  to  integrate  into  a  system  program. 


SERIAL  DATA  (DECODED  MANCHESTER) 
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SERIAL/PARALLEL  DATA  CONVERSION 


Figures  3.8a  &  b  represent  the  logical  flow  of  the  double  buffered  memories. 
This  particular  flowchart  follows  the  transmission  of  data  from  the  VME  backplane  to 
the  optical  transmitter.  The  logic  is  identical  for  received  data  coming  from  the 
optical  receiver  and  being  read  across  the  VME  backplane.  At  the  start  of  a  transmit, 
the  status  register  reveals  that  TxA  is  empty  and  can  be  written.  Initially  no  data  is  in 
either  Rx  buffer  so  no  data  can  be  read  to  the  optical  transmitter.  The  VME 
controller  begins  writing  to  TxA  until  it  is  full.  Then  a  status  read  will  reveal  a 
readable  buffer  that  will  immediately  be  transmitted  without  further  intervention  by 
the  VME  controller.  It  will  also  show  that  TxB  can  be  written  for  the  next 
transmission  while  TxA  is  currently  being  transmitted.  At  this  point  in  the  flowchart, 
the  reading  and  writing  of  buffers  becomes  independent.  If  there  is  an  empty  buffer, 
it  can  be  written  with  data  to  be  transmitted;  likewise  any  full  buffer  will  be 
immediately  transmitted.  If  at  any  time  both  transmit  buffers  are  full,  they  will  be 
transmitted  one  after  another  with  no  time  delay  between  buffers  and  no  data  can  be 
written  from  the  VME  controller  to  a  Tx  buffer  until  at  least  one  Tx  buffer  is  empty. 

This  controller  independent  toggling  of  buffers  allows  for  maximum  link 
bandwidth  utilization  while  requiring  minimal  VME  controller  service.  The  data  flow 
for  received  data  can  use  this  same  flowchart  with  the  exception  that  data  is  being 
written  from  the  optical  receiver  and  read  by  the  VME  controller.  The  transmit  and 
receive  buffers  are  also  independent  of  each  other  allowing  for  simultaneous  operation 
of  each  buffer  pair. 


Figure  3.8a  DOUBLE  BUFFER  CONTROL  FLOWCHAR 

Part  1  of  2 


Figure  3.8b  DOUBLE  BUFFER  CONTROL  FLOWCHAR 

Part  2  of  2 
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3.3.6  Time  Delay  of  Fiber  Optic  Interface 

For  transparent  link  operation,  the  system  user  should  not  be  able  to  discern 
the  delay  added  to  the  data  packets  due  to  traversing  the  link.  Ideally,  in  a  non-link 
supported  system,  data  would  be  transferred  directly  among  modules  and  not  travel 
any  unnecessary  paths.  For  this  system;  however,  the  data  needs  to  be  formed  into 
packets,  transmitted  to  the  opposite  end  of  the  link,  and  the  disassembled  before 
reaching  its  destination. 

For  some  paths,  the  extra  delay  is  of  no  consequence.  For  example,  data  that 
is  transmitted  up  the  link  for  recording  will  not  be  affected  by  additional  delay;  the 
only  concern  is  to  handle  the  data  in  real  time  so  that  it  is  recorded  as  fast  as  it  is 
created.  Some  data  paths;  however,  depend  heavily  on  available  data.  The  most 
restricting  requirement  comes  from  raw  acoustic  data  that  is  processed  to  form  new 
UUV  commands.  In  this  scenario,  raw  acoustic  data  from  the  UUV  needs  to  be 
processed  in  powerful  array  processors  located  on  the  launch  platform.  Decisions 
from  this  processing  are  formulated  and  then  transmitted  back  down  the  link  for 
control  of  the  UUV.  The  hardware  allows  for  real  time  transmission  of  all  the  data, 
but  adds  a  handling  delay  that  can  be  determined. 

This  delay  is  easily  calculated  as  a  sum  of  the  hardware  delays  of  the  FO- 
VME  I/F  and  fiber. 

Total  Delay  =  Iwrite buffer  ■*"  ^XMIT  buffer  ■*"  IfIBERDEIAY  IrEAD  BUFFER  (3-1) 
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where; 

twRiTE  BUFFER  =  time  requifcd  by  the  VME  controller  to  write  to  a  transmit 
buffer 

txwn-  BUFFER  =  tittle  required  to  read  a  transmit  buffer  serially  to  the  link 
tpiBER  DEij\Y  =  optical  delay  added  by  fiber 

tREAD  BUFFER  =  time  required  by  the  VME  controller  to  read  a  receive  buffer 

Using  the  following  characteristics  of  the  FO-VME  I/F  and  fiber: 

VME  read  and  write  speed  =  25  MBytes/second 

Buffer  size  =  32  kBytes 

Link  Speed  =  16  MBits/second 

Fiber  Length  =  20  km 

Refractive  Index  (n)  =  1.476 

The  solution  to  equation  3.1  is  the  following. 

19.09  ms  =  1.31  ms  4-  16.384  ms  +  98.3  us  +  1.31  ms 

The  time  delays  created  from  the  buffer  operations  are  easily  calculated  by 
dividing  buffer  size  by  speed  to  obtain  time.  Finally,  the  delay  added  by  the  fiber  is 
approximately  equal  to  the  length  of  the  fiber  (1)  divided  by  the  speed  of  light  (c) 
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multiplied  by  the  refractive  index  (n)  as  shown  in  equation  3.2.  This  result  is 
expressed  in  seconds. 

^FIBER  DELAY  0  *  n)/C  (SCCS)  (3.2) 

This  total  delay  of  19.09  ms  is  for  a  one  way  transmission  across  the  link. 
For  the  example  stated  above  for  UUV  control,  the  total  delay  would  be  a  minimum 
of  38.18  ms  from  the  time  raw  acoustic  data  resides  in  the  UUV  VME  controller  to 
the  time  a  decision  based  on  this  data  resides  in  the  same  VME  controller  in  the 
UUV.  For  this  application,  this  calculated  delay  was  negligible. 

3.3.7  Status  and  Control 

The  FO-VME  I/F  board  contains  three  registers:  two  status  and  one  control. 
Their  function  is  to  provide  the  VME  controller  with  information  about  the  board 
during  use.  The  status  registers  contain  information  on  memories  such  as  full  or 
empty,  and  which  of  the  dual  buffers  is  ready  or  in  progress  for  reading  and  writing. 
Information  of  this  kind  can  be  used  by  the  VME  controller  to  determine  if  a  transmit 
can  occur,  and  in  the  case  of  an  error,  determine  which  memory  is  failing  and  reset 
its  conditions  in  an  attempt  to  continue  its  use. 

In  addition  to  the  status  registers  designed  and  added  to  the  board,  the  VIC068 
contains  over  fifty  registers  that  are  shared  between  the  FO-VME  I/F  board  and  the 
VME  controller.  These  additional  registers  contain  VME  related  information  and  are 
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used  for  configuration  of  the  board  so  it  can  be  used  in  a  specific  VME  system.  The 
sharing  of  these  registers  allows  the  circuitry  on  the  FO-VME  I/F  board  to  exchange 
information  related  to  VME  activity  without  the  need  for  additional  custom  designed 
hardware  on  the  FO-VME  I/F  board. 

Finally,  there  is  one  write-only  control  register  unique  to  FO-VME  I/F  board. 
This  register  permits  the  VME  controller  to  have  limited  control  over  some  of  the 
board’s  functions.  For  example,  the  control  register  can  put  the  board  into  a  reset 
mode  that  clears  and  resets  the  dual  buffers  or  it  can  prohibit  data  from  leaving  or 
entering  the  board.  The  addition  of  this  control  register  aids  in  a  board  recovery  in 
the  event  of  a  critical  error. 

3.3.8  Operation  Modes  of  the  FO-VME  I/F 

Independent  of  VME  activity,  the  FO-VME  I/F  board  has  three  modes  internal 
to  its  design  that  are  always  functioning.  These  three  modes  are  a)  status  and  control 
update,  b)  interrupt  generation,  and  c)  VME  accesses.  The  interdependence  of  the 
mode  operations  is  displayed  in  a  flowchart  in  figure  3.9. 

The  first  mode  updates  the  status  and  control  registers  unique  to  the  FO-VME 
I/F  board.  The  VIC  chip  provides  a  programmable  local  timer  that  can  function  as  a 
tick  timer  to  initiate  local  activity.  On  this  board  the  timer  is  set  at  1000  Hz  and  is 


used  to  interrupt  the  board  so  that  the  status  and  control  registers  can  be  updated.  As 
shown  in  figure  3.9,  this  mode  has  the  highest  board  priority.  While  the  board  cycles 


Figure  3.9  FO-VME  I/F  MODE  FLOWCHART 
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through  its  modes,  it  checks  for  the  arrival  of  a  1000  Hz  tick  first  before  checking  the 
need  for  a  different  mode.  The  reason  for  this  priority  is  twofold.  First  the  time 
required  for  a  status  update  is  small  in  comparison  to  a  VME  access  so  timely  status 
is  always  available.  Second,  because  access  to  the  registers  will  override  the  other 
two  modes,  it  is  possible  for  the  VME  controller  to  access  a  board  that  is  failing  and 
possibly  reset  the  board  before  a  critical  failure  occurs.  Any  other  priority  could 
hinder  timely  status  updates  and  potentially  put  the  board  into  a  "lock  up"  state 
without  a  software  capability  to  determine  status. 

The  second  mode  pertains  to  generating  interrupts  on  the  VME  backplane. 
Whenever  a  Rx  buffer  is  filled  with  new  received  data  from  the  link,  the  FO-VME 
I/F  must  let  the  VME  controller  know  so  that  the  data  can  be  removed  before  the 
buffer  is  needed  again  by  the  link.  By  generating  an  interrupt  that  is  broadcast  to  the 
controller,  the  board  is  requesting  service.  It  is  then  the  responsibility  of  the  VME 
controller  to  read  all  of  the  relevant  data  from  the  buffer  and  then  free  up  space  for 
the  next  alternate  receive  packet.  If  data  is  not  removed  and  both  buffers  are  filled, 
new  data  received  from  the  link  will  be  lost. 

The  last  mode  provides  slave  accesses  for  reading  and  writing  Rx  and  Tx 
buffers.  Although  this  last  mode  has  the  lowest  priority  on  the  board,  it  plays  the 
most  significant  role.  When  the  VME  controller  wants  to  acces'  ?i  FO-VME  I/F 
board,  it  issues  a  local  bus  request  that  is  decoded  by  the  board  to  be  accessed.  The 
board  will  enter  the  slave  access  mode  and  then  check  to  see  if  there  is  a  buffer  that 
can  be  read  or  written;  if  not,  it  will  not  grant  access.  If  access  is  granted,  the  local 
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bus  on  the  FO-VME  I/F  is  opened  to  the  VME  bus  and  data  transfers  can  occur.  The 
largest  transfer  that  can  occur  is  256  transfers  of  32  bit  words  (1  kByte).  After  a 
transfer  of  any  size,  the  access  is  lost  and  must  be  reinstated  between  the  controller 
and  the  FO-VME  I/F. 
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CHAPTER  4 
TESTING 

Thorough  testing,  both  in  the  laboratory  and  in  the  field,  was  undertaken  to 
prove  the  feasibility  of  a  UUV  with  remote  command  and  control  provided  over  a 
fiber  optic  link.  The  tests  were  performed  in  stages  that  steadily  increased  in 
complexity,  culminating  in  actual  complete  system  tests  performed  in  an  underwater 
environment.  Although  it  is  not  an  objective  of  this  thesis  to  determine  a  bit  error 
rate  (BER)  for  the  optical  and  electronic  subsystems,  enough  data  was  gathered  to 
confirm  the  effectiveness  of  this  technology  for  undersea  use. 

To  aid  in  all  facets  of  testing,  electronic  and  optical  test  equipment  was  used. 
For  this  research  a  optical  power  meter  and  optical  time  domain  reflectometer 
(OTDR)  were  obtained.  The  test  equipment  was  extremely  valuable  for  laboratory 
and  ultimately  field  testing.  Their  presence  is  very  helpful  for  optical  link 
development. 

4.1  Laboratory  Test 

Before  going  to  the  field  for  final  testing  and  analysis,  a  series  of  tests  were 
performed  in  the  laboratory  to  ensure  reliable  and  safe  operation  of  the  UUV 
electronics.  Specifically,  three  tests  -  loopback,  ramp  data,  and  puretone  -  scrutinized 
the  system  and  allowed  for  an  almost  flawless  system  performance  in  the  field. 
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4.1.1  Loopback  Test 

Testing  of  only  the  hardware  that  contained  the  fiber  optic  link  (FO)  related 
components  was  done  to  ensure  the  integrity  of  the  transmission  path  from  the  VME 
bus  to  the  VME  bus  on  the  opposite  side.  The  first  was  the  loopback  test.  As  seen 
in  Figure  4. 1 ,  the  test  set  was  made  up  of  two  VME  chassis,  each  only  containing  a 
VME  controller/processor  (PME-63)  and  the  FO  boards,  the  FO-VME  I/F  and  the  the 
optics.  Connecting  the  two  VME  chassis,  via  the  FO  boards,  was  a  20  km  spool  of 
fiber.  The  Sun  workstation  acted  as  the  monitor  to  initialize  testing  and  to  view 
results. 

The  test  was  written  in  Ada  and  loaded  into  PROMs  located  on  the  two  PME- 
63s.  One  PME-63  was  the  master,  the  other  the  slave.  Initiation  of  the  test  sent 
32  kbyte  (the  size  of  a  FO-VME  buffer)  packets  of  known  32-bit  long  data  words  up 
the  link  from  the  master.  The  slave  read  the  packet  from  the  FO-VME  I/F, 
incremented  values  by  one,  and  then  returned  the  packet.  When  received  back,  the 
master  checked  the  values  for  the  correct  increment,  incremented  them  by  one,  and 
sent  the  new  packet  back  up  the  link.  The  test  was  varied  by  changing  the  number  of 
packets  to  be  sent  (up  to  2^^  and  the  speed  (up  to  100%  link  utilization)  at  which  they 
were  sent. 

The  objective  of  this  initial  test  was  to  debug  the  custom  built  hardware.  The 
loopback  test  was  very  effective  in  revealing  errors  in  timing  and  logic.  It  was  used 
to  eventually  debug  four  sets  of  custom  designed  hardware.  After  correction  of  the 
identified  problems,  the  test  was  re-run  for  about  24  hours  and  resulted  in  few  or  no 


Figure  4.1  CONFIGURATION  FOR  LOOPBACK  TEST 
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data  errors.  Because  of  the  comparison  done  in  the  test,  one  error  meant  one  long 
word  was  corrupt.  The  actual  error  could  encompass  from  one  to  thirty-two  bits. 

The  nature  of  the  loopback  test  did  not  warrant  precise  error  handling  or  recording. 

As  expected,  the  outcome  only  proved  the  fiber  optic  electronics  and  the  optical  link 
was  sound  for  fast,  simultaneous  bidirectional  data  transfers. 

4.1.2  Ramp  Data  Test 

The  custom  FO  boards  were  integrated  into  the  system  and  the  system  was 
ready  for  the  next  level  of  test.  A  test  fixture  was  constructed  that  functioned 
according  to  the  specification  of  the  actual  acoustic  array.  Instead  of  providing 
acoustic  type  random  data,  it  produced  incremental  data  in  the  form  of  a  ramp 
function.  Its  output  data  was  continuous  16  bit  parallel  words,  where  each  pair  of 
data  represented  the  real  and  imaginary  components  of  actual  data.  Each  data  point 
was  incremented  by  one  over  the  previous  data  point.  Figure  4.2  graphically  displays 
the  ramp  data  input.  This  test  fixture  allowed  for  a  more  thorough  and  realistic  test. 
Figure  4.3  shows  the  setup  for  the  ramp  data  test. 

At  this  point  the  setup  now  contained  portions  of  code  to  be  included  in  the 
final  system.  Ramp  data  was  injected  into  the  system  in  place  of  acoustic  data,  and 
transmitted  up  its  link  via  the  PME-63  and  FO-VME  I/F  board.  Received  data  on  the 
other  side  of  the  link  was  recorded  onto  optical  disks  via  the  PME-63  and  SCSI 
boards.  AH  test  code  is  contained  in  the  PME-63  and  is  bootable  and  commences  on 


power  up. 


xlO-* 
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Sample  Count 

Figure  4.2  RAMP  DATA  INPUT 
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Figure  4.3  CONFIGURATION  FOR  RAMP  DATA  &  PURETONE  TESTS 
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Although  in  the  test  the  FO  link  was  running  at  full  bandwidth,  16  Mbits/ sec, 
only  the  acoustic  data  was  checked  for  accuracy;  this  makes  up  6.25  percent  of  the 
transmitted  data.  During  the  test;  however,  the  controller  was  still  sending  and 
receiving  full  32  kbyte  packets  of  data.  The  data  was  extracted  by  reading  the  data 
and  control  disks.  This  combination  of  data  and  control  information  allowed  for  the 
formatted  data  to  be  located  and  recovered.  The  data  was  checked  for  incremental 
data  one  16  bit  longword  at  a  time.  Discrepancies  were  printed  to  the  screen.  Figure 
4.4  shows  a  sample  screen  with  correct  data,  and  an  induced  error. 

Table  4. 1  shows  the  results  of  five  ramp  data  tests,  representing  more  than  250 
MBytes  of  acoustic  data.  Assuming  the  BER  of  the  optical  link  is  equal  to  10  at 
most  two  bit  errors  should  have  occurred  in  this  data  sampling.  As  Table  4. 1 
portrays,  no  bit  errors  occurred,  and  this  is  a  total  system  check,  not  just  a  test  of  the 
FO-VME  I/F  electronics  and  the  optical  link.  Besides  the  optical  link,  the  BER  of 
the  electronics  transferring  data  on  each  side  of  the  link  in  addition  to  the  error  rate  of 
the  optical  recording  medium  used.  In  conclusion  the  system  and  the  optical  link 
performed  satisfactorily  and  better  than  expected.  The  purpose  of  this  test  was  not  to 
derive  the  BER  of  the  system,  but  rather  to  do  a  predictable  whole  system  check  that 
would  reveal  errors  too  large  in  magnitude  to  be  accepted.  Later  field  tests  revealed 


no  noticeable  errors. 
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Processing  Ping  4.000000 
Processed  100.000000  samples 
Processed  200.000000  samples 
Processed  300.000000  samples 
Processed  400.000000  samples 
Processed  500.000000  samples 
An  Error  Occured  at  time  500.000000  samples 
Imag  Beam  3  28091.000000  28090.000000 

Processed  600.000000  samples 
Processed  700.000000  samples 
Processed  800.000000  samples 
Processed  900.000000  samples 
Processed  1000.000000  samples 
Processed  1100.000000  seimples 
Processed  1200.000000  samples 
Processed  1300.000000  samples 
Processed  1400.000000  samples 
Processed  1500.000000  samples 
Processed  1600.000000  samples 
Processed  1700.000000  samples 
Processed  1800.000000  samples 
Processed  1900.000000  samples 
Processed  2000.000000  samples 
Processed  2100.000000  samples 
Processed  2200.000000  samples 
Processed  2300.000000  samples 
Processed  2400.000000  samples 
Processed  2500.000000  samples 
Processed  2600.000000  samples 
Processed  2700.000000  samples 
Processed  2800.000000  samples 
Processed  2900.000000  samples 
Processed  3000.000000  samples 
Processed  3100.000000  samples 
Processed  3200.000000  samples 
Processed  3300.000000  samples 
Processed  3400.000000  samples 
Processed  3500.000000  samples 
Processed  3600.000000  samples 
Processed  3700.000000  samples 
Processed  3800.000000  samples 
Processed  3900.000000  samples 
Processed  4000.000000  samples 
Processed  4100.000000  samples 
Processed  4200.000000  samples 
Processed  4300.000000  samples 
Processed  4400.000000  samples 
Processed  4500.000000  samples 
Processed  4600.000000  samples 


Figure  4.4  RAMP  DATA  TEST  SAMPLE  SCREEN  PRINTOUT 
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Table  4.1 

Ramp  Data  Test  Results 


Test# 

Quantity  of  Data 

Bit  Errors 
Recorded 

1 

55  Mbytes 

0 

2 

54  Mbytes 

0 

3 

55  Mbytes 

0 

4 

55  Mbytes 

0 

5 

54  Mbytes 

0 

Total 

273  Mbytes 

0 

Fiber  - 

Length  = 

19.8  km 

Rx  Input  Power  1300  nm  =  -27.4  dBm  (launch  platform) 
1550  nm  =  -25.5  dBm  (UUV) 

BER  -  Expected  =  1.000  x  10  ’ 


4.1.3  Pure  Tone  Test 

The  laboratory  testing  satisfied  only  preliminary  testing  requirements,  so  a  test 
was  needed  to  test  the  entire  system  out  of  water.  To  accomplish  this,  an  artificial 
stimuli  was  needed  to  form  an  input  to  the  acoustic  array.  The  objective  of  the  test 
was  to  verify  that  the  system  was  operating  rorrectly  and  accurately  from  sensors  to 
recording.  Again,  in  figure  4.3  the  test  st  shown.  The  setup  is  identical  to  the 
ramp  data  test  setup,  except  for  the  removal  of  the  test  fixture  and  the  addition  of  the 


actual  acoustic  data  interface.  The  stimuli  to  the  sonar  had  to  be  predictable  so 
analysis  would  be  possible. 

The  puretone  test  consisted  of  a  single  frequency  puretone  injected  into  the 
sonar  via  a  pressure  transducer.  Although  the  system  would  manipulate  the  received 
data  by  downconverting  and  filtering,  the  transfer  function  of  the  sonar  was  known 
and  hence  the  recorded  data  could  be  calculated.  The  input  puretone  passed  through 
many  components,  active  and  passive,  so  the  test  could  not  determine  a  BER. 

Rather,  it  was  used  to  test  the  reliability  of  the  electronics  system  and  FO  link.  It 
was  also  easy  to  perform.  The  setup  for  the  test  differed  very  slightly  from  the  final 
configuration,  and  a  large  subset  of  the  data  could  be  checked  in  about  one  hour. 

Sections  4. 1.3.1  and  4. 1.3.2  describe  two  unique  analyses  performed  on  the 
tonal  data  to  support  system  functionality  and  reliability.  The  analysis  shifts  from 
locating  bit  errors  to  locating  holes  in  the  data  that  could  give  invalid  acoustic  signal 
representatic  i  the  complete  system,  random  bit  errors  would  most  likely  go 
unnoticed  because  of  data  manipulation  such  as  averaging  and  smoothing  algorithms. 

4.1.3.1  Complex  Data  Visualization 

Visualization  of  the  puretone  data  made  data  analysis  fast,  accurate,  and 
simple.  Data  from  the  sonar  was  in  the  form  of  two  16  bit  words,  one  real  and  one 
imaginary.  This  complex  data  can  be  written  as  e  or,  converted  to  the 
trigonometric  form,  it  is  stated  as  cos(«  +  <!>)+}  sin(a)  +  4>),  where  w  is  the  input 
operating  frequency  and  <t>  is  the  initial  phase  offset.  The  trigometric  equation  is  in 
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the  form  representing  the  radius  of  a  circle,  thus  allowing  a  time  sampling  of  the 
continuous  complex  data  to  assume  a  circular  shape.  Each  plotted  point  will 
determine  a  point  on  the  perimeter  of  a  circle  and  the  connected  points  will  display  a 
circle  with  a  defined  perimeter  thickness.  The  thickness  is  derived  from  the  sampling 
and  input  frequencies.  Figure  4.5  displays  an  actual  plot  of  puretone  data  with  no 
missing  data.  The  sampling  frequency  also  defines  the  perimeter  distance  between 
two  consecutive  points  and  this  is  where  the  complex  data  visualization  is  important. 
As  viewed  in  figure  4.6,  a  plotted  point  was  intentionally  omitted  to  portray  the 
method.  Because  of  the  missing  sample,  the  connecting  line  between  two  points  is 
longer  than  expected  and  the  circle  shows  a  noticeable  flaw  that  is  the  result  of  a 
missing  data  from  the  electronics  subsystem. 

This  visual  analysis  is  also  preferred  over  FFTs  for  viewing  the  spectrum, 
because  the  system  noise  in  a  typical  spectrum  does  not  have  a  traceable  source. 
Portions  of  the  system  noise  were  due  to  sonar  filtering,  but  it  is  difficult  to  determine 
if  any  was  due  to  the  FO  link.  Each  complex  plot  represented  about  600  kbytes  of 
data  and  about  10  such  plots  would  exhaustively  test  all  the  recorded  raw  data  from  a 
short  laboratory  test. 

The  amount  of  missing  data  complex  visualization  could  detect  is  one  sample 
or  four  bytes;  in  addition,  a  corrupt  MSB  but  would  also  be  distinguishable.  The 
puretone  test  was  run  several  times  before  each  field  run,  and  never  revealed  a  fault 


with  the  FO  electronics. 
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Figure  4.5  TEST  FREQUENCY  SIGNAL 
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Figure  4.6 
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4. 1.3.2  Spectral  Analysis 

Much  in  the  same  manner  field  data  was  analyzed,  laboratory  test  data  could 
be  analyzed  by  performing  an  FFT  on  the  data  and  graphically  displaying  the  results. 
The  FFT  has  the  following  advantages  over  the  complex  visualization  method:  it 
checks  system  performance  and  verifies  the  frequency  components  of  the  test;  and,  by 
checking  the  frequency  components,  verifies  that  periodic  data  is  not  missing.  It  is 
possible  that  the  complex  visualization  method  would  overlook  missing  periodic  data 
because  the  remaining  data  could  still  produce  a  good  circular  plot. 

Figures  4.7  and  4.8  show  a  sample  input  tone  and  a  frequency  plot  of  the 
recovered  data  after  traversing  the  FO  link.  It  is  evident  from  the  spectrum  content 
that  the  signal  stays  intact.  Also,  the  recovered  time  series  displayed  in  figure  4.9 
shows  a  reconstructed  puretone.  The  jagged  reconstruction  is  due  to  sampling. 


4.2  Field  Test 

From  the  Fall  of  1991  to  early  1993,  twelve  in-water  experimental  tests  were 
attempted  that  tested  the  reliability  of  the  FO  subsystem.  Overall  there  was  great 
system  success,  and  system  performance  related  to  the  remote  control  and  operation 
of  the  UUV  was  outstanding.  Table  4.2  lists  the  in-water  tests  attempted  and  their 
outcome.  A  tabulation  of  this  run  data  shows; 

2  -Fiber  Breaks 

10  -Run-as  Planned 


12  -Total 


dB/DIV  RANGE  -18.0  dBv  -B3.41  dBv 


Figure  4.7  INPUT  FREQUENCY  POWER  SPECTRUM 


RECOVERED  OUTPUT  FREQUENCY  TIME  SERIES 
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TABLE  4.2 

IN-VVATER  RUN  TEST  RESULTS 


TEST 

DURATION 

COMMENTS 

;  1 

2  min 

Fiber  break 

2 

— 

Fiber  Integrity  Test  at  Launch 

Run-as  Planned 

3 

— 

Fiber  Integrity  Test  at  Launch 

Run-as-Planned 

4 

— 

Fiber  Integrity  Test  at  Launch 

Run-as-Planned 

5 

10.5  min 

Run-as-Planned 

6 

10.5  min 

Run-as-Planned 

7 

51  sec 

Fiber  Break  at  launch 

8 

10.5  min 

Run-as-Planned 

9 

10.5  min 

Run-as-Planned 

10 

10.5  min 

Run-as-Planned 

11 

12  min 

Run-as-Planned 

12 

10  min 

Run-as-Planned 
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The  two  fiber  breaks  will  be  discussed  in  Chapter  6.  The  10  successful  data 
runs  netted  about  350  MBytes  of  data.  The  data  was  broken  down  and  divided  into 
acoustic  cycles.  Each  acoustic  cycle  contained  acoustic  blocks  that  were  inspected  for 
frequency  content.  The  data  for  each  acoustic  block  was  FFT’d  and  inspected 
graphically.  The  level  of  FO  subsystem  electronics  data  integrity  that  could  be 
determined  from  the  test  is  limited.  The  smallest  increment  of  missing  data  to  be 
easily  detected  would  be  one  sample  (4  bytes).  Missing  one  sample  would  create  a 
true  discontinuity  and  cause  a  phase  shift  that  would  be  revealed  in  the  FFT.  For  all 
ten  valid  runs,  there  were  no  obvious  missing  samples  revealed  in  the  data  analysis. 

A  certain  BER  is  inherent  to  its  system  (~  10  ’  by  optical  component  specifications) 
but  its  effects  were  not  noticed  in  the  different  processes  performed  on  the  data. 

Because  of  the  complexity  of  the  retrieved  data,  it  is  not  possible  for  an  FFT 
alone  to  verify  the  results;  thus  verification  came  in  two  forms.  First,  during  any 
particular  test,  known  signal  sources  were  present  in  the  water  and  their  position 
relative  to  the  UUV  was  monitored  and  recorded.  The  acoustic  information  gathered 
from  these  sources  was  verified  to  be  contained  in  the  data  recorded  through  the  link 
electronics. 

A  second  verification  of  data  retrieved  through  the  FO  link  electronics 
occurred  one  year  after  the  first  field  tests.  Similar  in-water  runs  were  performed 
that  did  not  use  the  fiber  optic  link  and  recorded  data  on  optical  drives  internal  to  the 
UUV  system.  Because  of  the  similarity  of  acoustic  data  collected,  it  was  possible  to 
perform  comparisons  to  the  FO  link  retrieved  data.  Comparisons  concluded  that  the 
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data  from  1991  were  valid  and  was  a  true  representation  of  the  acoustic  information 
present  in  the  water.  Discussion  of  this  graphical  analysis  and  comparison  is  complex 
and  tedious,  and  is  outside  the  scope  of  this  thesis. 
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CHAPTER  5 
FUTURE  EXTENSIONS 

5.1  The  Future  in  Tethered  Vehicles 

UUVs  with  fiber  optic  payout  capabilities  have  become  increasingly  popular  in 
recent  years.  Companies  like  Optelecom,  Northern  Telecom,  Sippican,  and  SAIC 
Maripro  all  offer  variations  or  services  based  on  this  technology.  Applications  for 
this  technology  include:  a)  rapid  deployment  of  communication  links,  b)  tethered 
sonobouys,  c)  deployment  of  expendable  oceanographic  data  acquisition  equipment  for 
measuring  salinity,  current,  pressure,  and  depth,  d)  ordnance  disposal,  e)  harborside 
security  and,  f)  deep  water  search  and  salvage  [I]. 

Our  original  fiber  optic  tethered  vehicle  was  specifically  designed  and  built  for 
one  project.  All  of  its  requirements  were  derived  from  goals  set  by  this  project,  and 
from  space  occupied  by  the  electronics  and  optics  chosen.  A  fiber  optic  tethered 
UUV  system  would  need  to  be  more  dynamic  and  adaptable  to  new  applications. 

This  may  be  accomplished  by  designing  in  more  general  purpose  interfaces  that  could 
easily  fit  most  users’  applications. 

The  fiber  optic  spool  could  be  housed  in  a  permanent  compartment  within  the 
vehicle.  A  new  UUV  layout  would  not  be  necessary  if  a  project  were  to  utilize  the 
spool.  In  addition,  an  electronic  interface  will  make  the  optics  transparent  to  the 
user.  The  electronic  interface  would  consist  of  a  wide  parallel  word  with  a  simple 


asynchronous  strobe  or  handshake.  The  bandwidth  of  the  new  link  would  be  suffi¬ 
cient  to  meet  any  current  or  near  future  needs.  The  user  only  needs  to  strobe  data,  at 
virtually  any  rate,  into  the  interface  and  the  data  will  be  available  intact  on  the  other 
end  of  the  link.  Each  project  has  the  requirement  to  multiplex  and  demultiplex  its 
own  data  and  interface  with  the  link  electronics.  Again,  all  of  the  optics  will  be 
transparent  to  the  user  and  will  not  affect  UUV  configurations.  The  following 
sections  describe  the  new  technology  that  will  support  this. 

5.2  Opto-Electronics 

Chip  sets  now  exist  to  assist  in  GBit/second  transmission.  HP,  Vitesse, 

AMCC  and  TriQuint  offer  such  chip  sets  as  standard  product.  With  their  availability, 
other  manufacturers  have  developed  standard  links  that  use  these  chip  sets.  The 
standard  products  are  aimed  at  the  Fiber  channel  and  HIPPI  interface  market,  but 
their  operation  is  generic  enough  for  any  use.  Two  such  manufacturers  are  Finisar 
and  Broadband  Communication  Products  (BCP).  The  basis  of  the  boards  Finisar  and 
BCP  have  developed  is  to  remove  the  work  of  developing  a  fiber  based  system  by 
hiding  the  optics.  Two  boards  could  be  connected  with  a  commercial  fiber  and  then 
the  user  would  have  to  strobe  data  into  a  wide  bit  word  interface. 

An  immediate  advantage,  besides  the  lack  of  optical  knowledge  needed,  is  the 
user  would  work  with  a  strobe  rate  that  is  20-40  times  slower  than  the  serial  link  rate. 
This  is  a  much  simpler  system  rate  to  work  with.  As  before,  the  development  boards 
will  offer  full  duplex  operations  using  a  single  fiber. 
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5.3  VME  Enhancements 

In  late  1992,  another  revision  was  completed  towards  the  finalizing  of  a  VME 

I 

64  specification.  The  most  noticeable  transitions  to  the  new  specification  is  the  use  of 
64  address  lines  and  64  data  lines.  Theoretical  VME  transfers  can  now  be  as  high  as 
80  MBytes/ second  and  the  address  space  increases  to  16  exabytes  (2^  bytes).  Even  at 
backplane  speeds  of  this  magnitude,  a  data  link  at  a  maximum  of  only  640  MBits/sec 
could  be  supported.  A  link  of  this  bandwidth  does  not  presently  appear  to  have  a 
function  for  a  UUV.  The  data  rate  of  16  MBytes/second  as  discussed  in  this  thesis 
would  be  sufficient  for  the  tasks  of  this  UUV  system. 

5.4  Summary 

It  is  difficult  to  accurately  predict  all  possible  future  configurations  of  UUVs. 
The  parameters  that  define  these  systems  are  even  more  of  an  unknown.  However, 
any  proposed  generic  UUV  FO  link  must  cover  the  extremes  of  distance,  speed,  data 
bandwidth,  and  UUV  size. 
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CHAPTER  6 
CONCLUSION 

6.1  System  and  Component  Problems 

6.1.1  Payout  Fiber 

Two  of  the  twelve  in-water  runs  involved  a  failure  due  to  the  fiber’s  breaking. 
The  first  of  these  breaks  occured  because  of  improperly  installed  hardware.  The 
cable  broke  at  launch  due  to  kinking  in  the  hose  that  is  meant  to  uncoil  and  protect 
the  fiber  at  launch.  This  error  did  not  point  to  the  fiber  as  a  source  of  blame,  rather 
to  the  deployment  setup.  The  deployment  setup,  however,  is  still  part  of  task  the 
required  to  use  fiber  as  a  transmission  medium. 

The  other  failure  occurred  at  51  seconds  after  launch  (scheduled  run  time  was 
20  minutes).  At  this  time,  the  remote  vehicle  sensed  the  loss  of  data  from  the  launch 
craft,  and  shut  down  the  system  electronics.  Because  of  the  methods  used  in  deploy¬ 
ment,  it  is  difficult  to  determine  where  the  break  occurred.  After  recovery  of  the 
UUV,  there  were  significant  lengths  of  cable  still  hanging  from  the  UUV,  indicating 
that  the  break  was  not  in  the  vicinity  of  the  UUV. 

6.1.2  System  Failures  Summary 

The  two  errors  identified  during  field  tests  were  repaired  by  trying  to  avoid  the 
circumstances  that  led  to  them.  This  meant  new  procedures  to  identify  potential 
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problems  before  they  occurred.  The  system  did  perform  exceptionally  well  with  a 
success  rate  of  83%  for  the  fiber  optic  subsystem  electronics. 

The  use  of  pre-run  test  in  the  laboratory  helped  tremendously  in  avoiding 
additional  errors.  The  complexity  of  the  entire  UUV  and  remote  control  system 
makes  the  possibility  of  a  failure  imminent;  however,  laboratory  tests  remove  the 
oversights  that  can  occur  when  the  operator  becomes  too  familiar  with  the  system  and 
this  familiarity  creates  a  false  sense  of  security  for  in-water  testing. 

6.2  Thesis  Summary 

The  results  presented  in  this  thesis  culminated  from  a  three  year  R  &  D  project 
for  which  a  major  objective  was  to  utilize  a  fiber  optic  data  communication  link  to 
provide  a  remote  command  and  control  platform.  System  operation  during  in-water 
testing  combined  with  laboratory  testing  demonstrated  the  tethered  UUV  met  all  of  its 
technical  requirements  cited  in  sa:tion  1.4. 

Presently,  most  payout  applications  use  optical  fibers  and  cables  manufactured 
for  other  applications.  With  a  wide  growth  of  this  application  area,  we  can  expect  to 
see  more  fiber  and  cable  developed  that  will  be  optimized  for  these  areas.  These 
include  stronger  fibers  with  a  thinner  buffer  for  high  speed  payout  and  cables 
ruggedized  for  the  harsh  undersea  environment.  The  other  components  used  for  the 
success  of  this  research  are  generally  commercial  off-the-shelf  parts  without  specific 
tolerances  for  undersea  use.  This  is  easily  acceptable  since  their  working  environ¬ 
ment  is  dry  and  reasonably  controlled. 
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The  operation  of  the  optical,  payout,  and  remote  command  and  control  systems 
was  excellent.  As  expected,  all  of  the  processing  equipment,  recorders,  and  commer¬ 
cial  and  custom  boards  performed  exceptionally  well  and  as  expected.  The  fiber  optic 
tether  operated  reliably  at  all  speeds  and  maneuvers. 
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